As communication network utilization and technology continues to escalate, the typical local area network (LAN) is simultaneously growing larger and denser, resulting in an exponential growth in the number of cord connections needed between ports in respective patch panels, communication switches, equipment, etc., to maintain appropriate network functionality. Each such connection typically entails a cord (cable) of suitable type connecting a pair of jacks, adapters, or other connector ports in the network. Sometimes the connected ports are only inches apart; other times, the ports are disposed relatively farther apart. As the density and volume of needed cabling has increased, “spaghetti” cabling, a term colorfully describing a dense, chaotic arrangement of cables and the resultant difficulty of tracking a single cable from end to end in the LAN, has correspondingly become more commonplace and more problematic.
A primary purpose of LANs is to strategically place most or all of the routing-determinative connective hardware of a network within a single location so as to increase the efficiency of reconfiguring routing and communications connections. This purpose is being significantly thwarted by the increased presence and severity of spaghetti cabling, particularly when larger LANs are involved.
Nevertheless, until fairly recently, LAN operators primarily maintained only manual documentation relating to LAN connections, an endeavor that has become increasingly daunting as LAN size and sophistication continues to proliferate. Under a manual documentation scheme, when changes were needed in a particular LAN configuration, the operator would be faced with the complex problem of determining whether and which cords needed to be added, removed, or transferred (re-routed on one end). The problem became even more complex when the order of such steps needed to be considered, i.e., which cord to change before which other cord. The problem became still more complex when one considered cord length issues. Assuming the LAN operator even kept accurate records about the length of cord used to maintain particular connections within the LAN, there would still be the formidable task of determining whether a particular cord was sufficiently long, for example, to be moved from a particular port on one network rack to a different port on another network rack.
In many of the LAN installations today, time is of the essence in completing required revisions to the LAN cabling configuration. For example, if electronic network equipment malfunctions, critical communications could be interrupted, necessitating rapid connection of a destination to a new source, which, in turn, requires a rapid change in the LAN cabling. When a revision to the LAN cabling configuration is made, it is essential that each step is performed correctly. If a cabling revision step is made incorrectly, it could disrupt vital communications.
In addition, given the high cost of technically skilled labor, employing an operator and one or more revisors to sporadically or continuously monitor and reconfigure a LAN, can be very costly. Thus, trying to efficiently reconfigure these spaghetti cable networks has become very complex, very time consuming, very confusing, and very costly. As such, there has been a need for an improved manner of monitoring and reconfiguring such systems. Fortunately, networking problems of the type described are efficiently addressed by computer algorithms, and some efforts have been made to address the problem of inefficient and costly reconfiguration in this manner.
In particular, the use of polling terminals in a patch panel and automatic documentation of configurational changes is disclosed in UK patent application GB2236398A to Carter et al, filed Sep. 29, 1989. “The Great Cabling Treasure Hunt” by Mary Jander, published Mar. 21, 1991 in Data Communications, discusses some ways in which software can help LAN administrators gain and maintain control over their organization's cabling resources. U.S. Pat. No. 5,483,467 to Krupka et al. discloses a particular example of such an application in which a computer or microprocessor employs a scanner to continuously sense the interconnection arrangement or configuration of the LAN cabling. Much in line with the teachings of the Carter application, Krupka discloses the logic circuitry of the computer or microprocessor receiving intermittent scanning inputs through a detection matrix to insure that the actual cabling configuration is in conformity with what is designed. The Krupka scanner may provide an interconnection status output to the computer or to a dedicated output device. One type of dedicated output device for displaying the interconnection status of a LAN is an array of lights disposed in corresponding relationship to particular ports within the LAN.
It is thus known to have a LAN with output lights associated with particular ports in the network wherein the lights are selectively lit to indicate information relating to the comparison between an existing connection pattern and a predetermined desired connection configuration. Such systems have proven to be fairly advantageous relative to the difficulty of manually monitoring, documenting, and changing configurations. Nevertheless, the automatic documentation and reconfiguration systems developed to date have significant shortcomings with regard to reconfiguring LAN cabling.
Reconfigurations typically entail a LAN revisor performing a series of revisions to the connections between ports by cords. Sometimes it is necessary to introduce a new cord to connect two previously open ports within the network, thereby adding (“addition”) a cord to the system. Other times, one needs to completely remove (“removal”) an already installed cord, thereby disconnecting the cord from two ports previously connected to one another. Sometimes, one end of a cord needs to be moved from one port to another (“transfer”) while the other end stays connected. In an automatic documentation and reconfiguration management system, such as one controlled by a computer or processor as described generally above, hereinafter called “the system,” a reconfiguration typically involves a series of instructions, i.e., additions, removals, and transfers, communicated by the system to the revisor, which may include communication by illuminating appropriate lights corresponding to the relevant ports where cords need to be plugged in or removed.
Currently, under one such automatic revision system, for example, to indicate a necessary “addition”, lights are illuminated adjacent the two ports into which the cord ends must be inserted. Since the system cannot ascertain a change in the configuration until both ends are plugged in, the lights do not change upon insertion of the first end of the cord, but both turn off when the second end is appropriately inserted. As such, when the revisor inserts the first end of the cord, there is no light signal or other confirmation to indicate whether he has correctly completed this step. Given the high density of data ports in current networks and the usual need for a reconfiguration to be performed quickly, the rate of revisor error is significant. Additionally, if the two lights are in places where they cannot be seen from where the revisor is standing, the revisor must first find both lights, visually approximate the distance between them, and guess at the minimal length of cord needed to connect the corresponding ports. Of course, a cord that is too short will result in a failed effort to make the connection, thereby wasting expensive time; a cord that is too long will produce wasteful slack that contributes to spaghetti cabling.
Currently for removals, lights are typically illuminated next to the two ports from which the respective cord ends must be removed. Since the connection to the system is broken by the removal of the first end from the first port, the system considers the cord “removed” when the first end is removed. For reasons of waste, cost, spaghetti cabling, and freeing the second port for future use, it is necessary to remove the second end of the cord. Because the cord is considered removed upon the removal of its first end, however, the two lights are both turned off at this point, thereby making it very difficult for the revisor to find the other end of the cord, particularly if the length of the cord is partially or totally hidden. Furthermore, the revisor will have no light indicator or other confirmation if and when he correctly performs the removal of the other end.
It is not known whether prior systems employ specialized routines for transferring a cord end from one port to another, but one might presume that transfers in prior systems are performed by breaking them down into a cord removal followed by a subsequent cord addition. Sometimes, such a procedure would result in the inefficient unplugging of a cord end from a port only to have the same end immediately reinserted into the same data port in the subsequent step. Thus, additions, removals, and transfers still can be very cumbersome with current electronic systems and have much inefficiency existent in current procedures.